08 RAG面试题

1、什么是RAG？

RAG 是 Retrieval-Augmented Generation 的缩写，中文一般叫“检索增强生成”。

它的核心思路很简单：模型回答问题前，先从外部知识库里检索相关资料，再把资料和用户问题一起交给大模型，让模型基于资料生成答案。

也就是说，RAG 不是让模型完全依赖自己参数里的知识回答，而是让模型“带着资料回答”。

流程大概是：

text

用户问题
  ↓
检索知识库
  ↓
找到相关文档片段
  ↓
把片段放进 Prompt
  ↓
大模型生成答案

例如用户问：

text

公司年假规则是什么？

模型本身不知道某个公司的内部制度。RAG 会先去企业知识库里检索“年假规则”相关文档，再让模型根据检索结果回答。

RAG 主要解决三个问题：

大模型不知道企业内部知识
大模型知识可能过期
大模型容易编造答案

有了 RAG，模型回答时可以引用最新、可控、可追溯的资料。

2、Agent为什么需要RAG？

Agent 需要 RAG，是因为 Agent 经常要处理真实业务问题，而真实业务问题往往依赖外部知识。

大模型虽然有通用知识，但它不知道你的公司制度、项目文档、数据库字段、接口说明、历史工单和业务规则。如果不接知识库，Agent 很容易凭感觉回答。

RAG 对 Agent 的价值主要有几个。

第一，补充私有知识。

比如企业知识库、产品文档、代码文档、客服 FAQ，这些内容不在模型训练数据里，需要通过检索提供给模型。

第二，降低幻觉。

让模型基于检索结果回答，比直接让模型自由发挥更可靠。尤其是要求“只基于资料回答”时，可以减少编造。

第三，保持知识更新。

业务文档更新后，只要重新入库或更新索引，Agent 就能使用新知识，不需要重新训练模型。

第四，支持可追溯。

RAG 可以返回引用来源，让用户知道答案来自哪篇文档、哪个章节。

第五，和工具调用配合。

Agent 可以先用 RAG 查知识，再调用工具执行操作。例如先查报销规则，再判断某张发票是否符合要求。

所以 RAG 对 Agent 来说，不只是一个问答能力，而是 Agent 获取外部知识的基础能力之一。

3、RAG完整流程是什么？

一个完整的 RAG 系统一般分成两个阶段：离线入库和在线问答。

离线入库阶段负责把知识库处理成可检索的数据。

流程如下：

text

原始文档
  ↓
文档解析
  ↓
清洗内容
  ↓
切分 Chunk
  ↓
生成 Embedding
  ↓
写入向量数据库

例如 PDF、Markdown、网页、数据库记录，都要先解析成文本。然后去掉无用内容，按合适粒度切成片段，再对每个片段生成向量，最后存入向量数据库。

在线问答阶段负责根据用户问题检索并生成答案。

流程如下：

text

用户问题
  ↓
问题改写（可选）
  ↓
生成 Query Embedding
  ↓
向量检索 TopK
  ↓
关键词检索（可选）
  ↓
Rerank 重排
  ↓
组装 Prompt
  ↓
大模型生成答案
  ↓
返回答案和引用来源

其中问题改写、关键词检索、Rerank 不是每个系统都必须有，但在生产环境里很常见。

在 LangChain v1.0 中，可以把检索器做成 retriever，再接到 Agent 或 chain 里使用。

在 LangGraph v1.0 中，更适合把 RAG 拆成多个节点：

text

rewrite_query 节点
  ↓
retrieve 节点
  ↓
rerank 节点
  ↓
generate_answer 节点

这样每一步都能单独调试，也方便加日志、Fallback 和人工审核。

4、Embedding是什么？

Embedding 是把文本转换成一组数字向量的过程。

大模型不能直接用“语义”做计算，所以需要把文本变成向量。语义相近的文本，生成的向量距离也会比较近。

比如：

text

“如何申请年假”
“年假怎么请”

这两句话字面不完全一样，但意思很接近。经过 Embedding 后，它们在向量空间里的距离通常也会比较近。

Embedding 的作用就是让系统可以做语义检索。

传统关键词搜索主要看字面匹配。如果用户问“年假怎么请”，文档里写的是“休假申请流程”，关键词可能对不上。但向量检索可以根据语义找到相关内容。

一个 Embedding 结果大概长这样：

text

[0.012, -0.231, 0.548, ...]

实际维度可能是几百维、上千维甚至更多。开发者通常不需要关心每一维代表什么，只需要知道：

text

文本 -> Embedding -> 向量检索

Embedding 的质量会直接影响 RAG 的召回效果。如果 Embedding 模型不适合中文、代码或某个专业领域，检索结果就可能不准。

5、向量数据库原理是什么？

向量数据库的核心作用是存储向量，并快速找到和查询向量最相似的一批向量。

在 RAG 中，每个文档 Chunk 会生成一个 Embedding 向量，并和原文、元数据一起存入向量数据库。

结构类似：

json

{
  "id": "chunk_001",
  "content": "员工入职满一年后可享受年假。",
  "embedding": [0.12, 0.34, ...],
  "metadata": {
    "doc_id": "hr_policy_001",
    "title": "员工休假制度",
    "page": 3
  }
}

当用户提问时，系统也会把问题转换成 query embedding，然后到向量库里找距离最近的 Chunk。

常见的相似度计算方式有：

Cosine Similarity：余弦相似度
Dot Product：点积
Euclidean Distance：欧氏距离

由于真实数据量可能很大，向量数据库通常不会逐条暴力比较，而是使用近似最近邻搜索算法，比如 HNSW、IVF 等，用较小的精度损失换取更快的检索速度。

向量数据库除了向量检索，还通常支持 metadata 过滤。

例如：

text

只检索 user_id = u_001 的文档
只检索 project_id = p_001 的知识库
只检索 status = published 的内容

这在多租户、权限控制、分业务线检索时非常重要。

6、Chunk如何切分？

Chunk 是文档切分后的文本片段。RAG 不会把一整篇长文档直接丢进向量库，而是先切成多个 Chunk，再分别生成 Embedding。

切分 Chunk 的目标是：每个片段既不能太长，也不能太碎，还要尽量保持语义完整。

常见切分方式有几种。

第一，按固定长度切。

比如每 500 个字切一段。这种方式简单，但容易把一个完整段落切断。

第二，按自然结构切。

比如按标题、章节、段落、列表切。Markdown、HTML、文档类内容更适合这种方式。

第三，按语义切。

根据语义边界切分，把同一个主题的内容尽量放在一起。这种效果更好，但实现成本更高。

第四，带重叠切分。

为了避免上下文断裂，相邻 Chunk 之间可以保留一部分重叠内容。

text

Chunk 1：第 1 - 500 字
Chunk 2：第 401 - 900 字

中间重叠 100 字，可以减少重要信息刚好被切断的问题。

实际项目里，常用做法是先按文档结构切，再对过长段落做二次切分，并保留一定 overlap。

对于代码、表格、FAQ、Markdown，最好按它们自己的结构切，不要一刀切。

7、Chunk大小如何确定？

Chunk 大小没有固定标准，要看文档类型、模型上下文长度、Embedding 模型效果和业务问题特点。

Chunk 太小，会丢上下文。

比如一个制度条款被切成两段，第一段写适用条件，第二段写具体规则，检索到其中一段时答案就不完整。

Chunk 太大，会带来两个问题。

第一，Embedding 表达不准。

一个 Chunk 里主题太多，向量会变得模糊，检索时不容易匹配具体问题。

第二，占用 Prompt 太多。

检索出来的内容太长，会挤占模型上下文。

常见经验是：

text

FAQ：一个问答对一个 Chunk
普通文档：300 - 800 中文字左右
技术文档：按小节切分
代码文档：按函数、类或模块切分
长报告：按标题层级切分，再做摘要

Overlap 一般可以设置在 Chunk 大小的 10% 到 20% 左右，太大会造成重复内容太多。

最稳妥的方法不是拍脑袋定，而是用真实问题做评估。比如准备几十个用户常见问题，测试不同 Chunk 大小下能否召回正确内容，再决定最终参数。

8、TopK如何选择？

TopK 指的是向量检索时取前 K 条最相似的结果。

比如 TopK=5，就是返回最相关的 5 个 Chunk。

TopK 太小，可能漏掉正确答案。TopK 太大，会带来噪声和 Token 消耗。

选择 TopK 时要考虑几个因素。

第一，问题复杂度。

简单事实类问题，TopK 可以小一点，比如 3 到 5。复杂问题需要综合多个文档，TopK 可以大一点，比如 8 到 15。

第二，Chunk 大小。

Chunk 越大，每条内容占用 Token 越多，TopK 就不能太大。Chunk 越小，可能需要更多条才能拼出完整上下文。

第三，是否有 Rerank。

如果后面有 Rerank，可以先召回多一点，比如 TopK=20，再重排后取前 3 到 5 条进入 Prompt。

第四，模型上下文限制。

最终进入 Prompt 的内容不能超过模型可承受范围。

常见生产做法是两段式：

text

向量召回 TopK = 20
Rerank 后取 TopN = 5

这样既提高召回率，又控制最终上下文长度。

TopK 不是一次设定后永远不变，最好根据业务评估结果持续调整。

9、Rerank有什么作用？

Rerank 是对初步召回结果进行二次排序。

向量检索速度快，但它只根据向量相似度判断相关性，有时会召回一些“看起来相似但不真正回答问题”的内容。

Rerank 的作用就是从候选结果里挑出更符合当前问题的内容。

流程一般是：

text

用户问题
  ↓
向量检索召回 20 条
  ↓
Rerank 模型重新打分
  ↓
取前 5 条进入 Prompt

Rerank 和向量检索的区别可以这样理解：

text

向量检索：快速粗筛
Rerank：精细排序

Rerank 通常会把“问题 + 候选 Chunk”一起输入模型，判断这个 Chunk 是否真正能回答问题。

它特别适合这些场景：

文档很多，召回噪声较大
业务术语相近，容易混淆
问题比较复杂，需要精确匹配
向量检索 TopK 取值较大

缺点是会增加延迟和成本，因为每个候选都要重新打分。所以一般不会对全量文档 Rerank，而是只对初步召回的一小批结果做。

10、如何提高检索准确率？

提高 RAG 检索准确率，一般要从数据、切分、检索策略和排序几个方面优化。

第一，清洗数据。

原始文档里如果有目录、页眉页脚、乱码、重复内容、无意义表格，都会影响检索效果。入库前要先清洗。

第二，优化 Chunk 切分。

按语义和文档结构切分，比固定长度硬切更稳定。标题、段落、表格、代码块最好分别处理。

第三，保留元数据。

每个 Chunk 要带上来源、标题、章节、时间、权限、业务线等信息，方便过滤和溯源。

第四，使用混合检索。

向量检索擅长语义相似，关键词检索擅长精确匹配。很多系统会把两者结合起来。

text

向量检索 + BM25 关键词检索 + 合并去重

第五，引入 Rerank。

先多召回，再重排，可以明显减少不相关内容进入 Prompt，千问提供了ReRank模型：Qwen3-VL-Rerank

第六，做 Query Rewrite。

用户问题可能很口语化，或者上下文不完整。可以先把问题改写成更适合检索的形式。

例如：

text

用户：那这个怎么申请？
改写：员工年假如何申请？

第七，做权限和范围过滤。

不要在全库里乱搜。根据用户、租户、项目、文档类型先缩小范围。

第八，用真实问题评估。

不能只看感觉，要用测试集看正确文档是否被召回、排名是否靠前。

在 LangGraph v1.0 里，可以把 query rewrite、hybrid retrieve、rerank、answer generation 拆成独立节点，逐步调优每一环。

11、如何解决知识库召回错误？

知识库召回错误通常有几类原因：文档质量差、切分不合理、Embedding 不合适、检索范围太大、TopK 设置不合理，或者用户问题本身不清楚。

解决时不要只盯着模型回答，要先看检索结果。因为很多 RAG 问题，根因不是生成错了，而是前面检索就错了。

可以按下面顺序排查。

第一，看正确文档有没有入库。

如果知识库里根本没有正确内容，模型不可能答对。

第二，看 Chunk 是否切坏了。

有时候正确答案被切到两个 Chunk 里，单独召回任何一个都不完整。

第三，看检索是否召回正确 Chunk。

如果正确 Chunk 没进 TopK，说明召回策略有问题，可以调整 Chunk、Embedding、TopK 或增加关键词检索。

第四，看正确 Chunk 排名是否太低。

如果正确内容召回了但排在后面，可以加 Rerank。

第五，看是否缺少过滤条件。

多租户、多项目、多版本文档混在一起，很容易召回错误版本。需要加 metadata filter。

第六，看问题是否需要改写。

用户说“上面那个”“这个流程”，如果不结合上下文改写，检索器可能不知道要查什么。

工程上常见的处理方式：

text

召回失败 → 增大 TopK / 混合检索
召回噪声多 → 加 Rerank / metadata 过滤
问题太口语 → Query Rewrite
文档太乱 → 清洗和重切 Chunk
版本混乱 → 加版本字段和发布时间过滤

另外，答案生成阶段也要有兜底规则。如果检索结果不足以回答，就应该明确说没有找到依据，而不是让模型编造。

12、如何评估RAG效果？

评估 RAG 不能只看最终回答好不好，因为 RAG 分为检索和生成两个环节。要分别评估。

第一，评估检索效果。

常见指标有：

Recall@K：正确文档是否出现在前 K 个结果里
Precision@K：前 K 个结果里有多少是真的相关
MRR：正确结果排名越靠前越好
Hit Rate：是否命中正确资料

比如用户问题有标准答案和对应来源文档，如果正确 Chunk 出现在 Top5，就算一次命中。

第二，评估生成效果。

主要看：

答案是否正确
是否基于检索资料
是否有幻觉
是否遗漏关键信息
表达是否清楚
引用来源是否准确

第三，评估端到端效果。

从用户角度看，最终要回答：这个系统能不能解决问题。

可以准备一批真实问题作为测试集：

json

{
  "question": "员工入职多久可以休年假？",
  "expected_answer": "入职满一年后可以享受年假",
  "expected_source": "员工休假制度"
}

每次改 Chunk、Embedding、TopK、Rerank 或 Prompt 后，都跑一遍测试集，比较效果变化。

第四，线上反馈。

上线后要记录用户是否追问、是否点赞、是否点踩、是否点击引用来源。这些都能反映 RAG 实际效果。

在 LangChain / LangGraph 体系里，可以结合 LangSmith 做链路追踪，观察每次请求检索到了哪些文档、Rerank 分数是多少、最终 Prompt 是什么、模型输出了什么。

一个成熟的 RAG 评估不会只看”模型答得像不像”，而是会把检索命中率、引用准确性、答案事实性和用户反馈一起看。

13、请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？有哪些优势？

RAG 的工作原理是：先从外部知识库中检索和用户问题相关的内容，再把这些内容作为上下文交给大模型生成答案。

它不是直接让模型凭参数记忆回答，而是让模型基于“检索到的资料”回答。

典型流程是：

text

用户问题
  ↓
问题向量化
  ↓
从知识库检索相关 Chunk
  ↓
重排和过滤
  ↓
把资料拼进 Prompt
  ↓
LLM 生成答案

和直接微调 LLM 相比，RAG 主要解决的是“知识更新”和“私有知识接入”的问题。

微调更适合改变模型行为、输出风格或学习某类任务模式，但不适合频繁注入大量事实知识。因为知识一旦变化，就要重新准备数据、训练、评估和部署，成本比较高。

RAG 的优势主要有几个。

第一，知识更新更方便。

文档变了，只需要更新知识库或索引，不需要重新训练模型。

第二，适合接入企业私有知识。

比如内部制度、产品文档、技术方案、客服工单、数据库说明，这些内容可以直接入库检索。

第三，成本更低。

相比微调大模型，构建和维护知识库通常成本更低，迭代也更快。

第四，可追溯。

RAG 可以返回引用来源，用户能看到答案依据来自哪篇文档、哪个段落。

第五，降低幻觉。

如果 Prompt 明确要求“只基于检索资料回答”，模型编造的概率会降低。

当然，RAG 不能完全替代微调。简单理解是：

text

RAG：解决模型不知道什么
微调：解决模型怎么回答、怎么执行任务

实际项目里，两者也可以结合使用。

14、RAG 怎么解决 LLM 上下文窗口有限的问题？

LLM 的上下文窗口是有限的，不能把整个知识库都塞进 Prompt。RAG 的做法是先检索，再只把最相关的一小部分内容放进上下文。

也就是说，RAG 不是扩大模型窗口，而是减少进入窗口的无关内容。

流程可以理解为：

text

大量文档
  ↓
切分成 Chunk
  ↓
建立索引
  ↓
用户提问时只召回相关 Chunk
  ↓
把少量 Chunk 放进 Prompt

例如知识库有 10 万篇文档，用户问“年假怎么申请”，系统只需要检索出和年假申请相关的 3 到 5 个片段，而不是把所有 HR 文档都给模型。

为了更好地适配上下文限制，通常会做这些优化。

第一，合理切分 Chunk。

Chunk 太大会占用大量 Token，太小又可能缺上下文。要根据文档类型选择合适粒度。

第二，控制 TopK。

初步召回可以多一些，但最终进入 Prompt 的内容要控制数量。

第三，使用 Rerank。

先召回较多候选，再重排后只保留最相关的内容。

第四，压缩上下文。

对过长内容可以做摘要、去重或抽取关键句，只保留回答问题需要的信息。

第五，使用 metadata 过滤。

先按租户、项目、文档类型、时间范围过滤，减少无关内容进入检索范围。

所以 RAG 解决上下文有限问题的核心是：用检索机制在海量知识中筛出最相关的小上下文。

15、如何选择一个合适的嵌入模型？评估一个 Embedding 模型的好坏有哪些指标？

选择 Embedding 模型时，不能只看排行榜，要看它是否适合自己的业务数据和查询场景。

主要考虑几个方面。

第一，语言能力。

如果知识库主要是中文，就要选择中文效果好的模型。如果是中英混合，要看跨语言和多语言能力。

第二，领域匹配度。

通用模型不一定适合代码、法律、医疗、金融、客服等垂直领域。领域术语多时，最好用真实业务数据评估。

第三，向量维度和检索成本。

维度越高，表达能力可能更强，但存储和检索成本也更高。

第四，最大输入长度。

如果 Chunk 较长，Embedding 模型的输入长度要能覆盖，否则会被截断。

第五，部署方式。

要考虑是用 API 还是本地部署，以及延迟、吞吐、成本、数据安全要求。

第六，和向量数据库的兼容性。

不同模型可能适合 cosine、dot product 等不同相似度计算方式，要和索引配置匹配。

评估 Embedding 模型的指标主要有：

Recall@K：正确 Chunk 是否能出现在前 K 个召回结果中
Precision@K：前 K 个结果中相关内容占比
MRR：正确结果排名是否靠前
nDCG：排序质量是否合理，越相关的结果是否越靠前
Hit Rate：是否命中正确资料
Latency：生成向量和检索耗时
Cost：调用成本或部署成本
Stability：相似问题的检索结果是否稳定

实际项目中，最重要的是用自己的测试集评估。

例如准备一批真实用户问题，每个问题标注标准答案和正确来源文档，然后比较不同 Embedding 模型的 Recall@5、MRR 和最终回答质量。

不要只看模型在公开榜单上的分数，因为公开数据集和业务文档可能差异很大。

16、在什么场景下，你会选择使用图数据库或知识图谱来增强或替代传统的向量数据库检索？

当问题不仅依赖语义相似度，还依赖实体关系、路径推理和结构化关联时，可以考虑使用图数据库或知识图谱。

传统向量检索擅长找“语义相似”的文本，但不擅长表达复杂关系。

比如下面这些问题就更适合图结构：

text

A 公司投资了哪些企业？这些企业的实际控制人是谁？
某个故障影响了哪些上游服务和下游服务？
某个药物和哪些疾病、症状、禁忌症有关？
某个员工属于哪个部门？部门负责人是谁？有哪些审批权限？

这些问题的关键不是找一段相似文本，而是沿着实体之间的关系进行查询和推理。

适合使用知识图谱的场景包括：

第一，实体关系很重要。

例如人物、组织、产品、合同、系统、服务之间存在明确关系。

第二，需要多跳推理。

例如从用户找到部门，再找到权限，再找到可访问文档。

第三，需要强约束和可解释路径。

图数据库可以返回关系路径，比单纯向量相似度更容易解释。

第四，结构化数据多。

如果数据本身来自数据库、CMDB、权限系统、交易系统，天然适合建图。

第五，向量检索容易混淆。

实体名称相似、业务术语相似时，图上的精确关系可以减少误召回。

不过，图数据库也不是万能的。它需要实体抽取、关系抽取、图谱维护，建设成本更高。

实际项目里更常见的是混合方案：

text

向量检索：召回相关文本
图检索：补充实体关系和推理路径
LLM：综合文本和结构化关系生成答案

这类方案通常也被称为 GraphRAG。

17、传统的 RAG 流程是”先检索后生成”，你是否了解一些更复杂的 RAG 范式，比如在生成过程中进行多次检索或自适应检索？

了解。传统 RAG 通常是一次检索、一次生成，但复杂问题往往一次检索不够，所以会使用更高级的 RAG 范式。

第一，Multi-hop RAG。

多跳 RAG 会把复杂问题拆成多个子问题，分多次检索。

例如：

text

问题：A 产品的负责人所在部门有哪些上线规范？

系统可能先查“A 产品负责人是谁”，再查“负责人属于哪个部门”，最后查“该部门上线规范”。

第二，Iterative RAG。

迭代式 RAG 会根据当前检索结果继续生成新的查询，再次检索，直到信息足够。

流程类似：

text

检索 → 发现信息不足 → 生成新查询 → 再检索 → 汇总答案

第三，Adaptive RAG。

自适应 RAG 会先判断问题是否需要检索、需要检索几次、用哪种检索方式。

比如普通闲聊不检索，事实问题走向量检索，精确编号问题走关键词检索，复杂问题走多轮检索。

第四，Agentic RAG。

Agentic RAG 会让 Agent 自己决定检索、调用工具、验证答案和继续追问。

它不是固定链路，而是一个带决策能力的流程。

第五，Corrective RAG。

系统会检查召回内容是否相关。如果检索质量差，可以重新检索、改写 query，或者返回“没有足够依据”。

第六，Self-RAG。

模型在生成过程中会自我判断是否需要检索、检索结果是否支持答案、答案是否需要引用。

这些复杂范式的共同目标是：不要把 RAG 写死成一次检索，而是根据问题复杂度动态调整检索策略。

在 LangGraph 中，这类流程很适合用图来表达，例如用条件边控制是否继续检索、是否重写问题、是否进入人工审核。

18、RAG 系统在实际部署中可能面临哪些挑战？

RAG 在 Demo 中看起来简单，但真实部署会遇到很多工程问题。

第一，数据质量问题。

企业文档常常有重复、过期、格式混乱、权限不清、版本冲突等问题。数据不干净，RAG 效果很难好。

第二，文档解析问题。

PDF、Word、PPT、网页、表格、图片里的文字都可能解析失败。表格和多栏 PDF 尤其容易丢结构。

第三，Chunk 切分问题。

切太碎会丢上下文，切太大会召回不准，还会占用大量 Token。

第四，检索准确率问题。

Embedding 模型不合适、TopK 不合理、缺少 Rerank、缺少关键词检索，都会导致召回错误。

第五，权限控制问题。

不同用户能看的文档不同，检索时必须做权限过滤，不能先检索再靠模型判断权限。

第六，延迟和成本问题。

一次请求可能包含 query rewrite、向量检索、BM25、Rerank、LLM 生成，链路越复杂，延迟和成本越高。

第七，知识更新问题。

文档更新后，索引要及时同步。还要处理删除、版本替换、增量更新和缓存失效。

第八，引用准确性问题。

答案说得对，不代表引用来源一定对。需要确保生成内容和引用 Chunk 对得上。

第九，评估困难。

RAG 既要评估检索，又要评估生成，还要评估用户体验。没有测试集时，很难判断优化是否有效。

第十，安全问题。

包括 Prompt Injection、越权检索、敏感信息泄露、恶意文档污染知识库等。

所以生产级 RAG 不只是“向量数据库 + LLM”，还需要数据治理、权限系统、监控评估、缓存、日志、灰度和安全策略。

19、什么是RAG中的”幻觉”问题？如何预防？

RAG 中的幻觉，是指模型生成了没有依据、和检索资料不一致，或者看起来合理但实际错误的内容。

RAG 虽然能降低幻觉，但不能完全消除幻觉。

常见幻觉来源有几种。

第一，检索结果本身不相关。

如果召回内容错了，模型可能基于错误上下文生成错误答案。

第二，检索结果信息不足。

资料里没有答案，但模型为了满足用户，可能编出一个答案。

第三，Prompt 约束不够。

如果没有明确要求“只基于资料回答”，模型可能混入自己的常识。

第四，多个文档互相冲突。

模型可能随便选择一个版本，或者把多个版本混在一起。

第五，引用不准确。

答案内容和引用来源对不上，也是一种 RAG 幻觉。

预防方式包括：

第一，提高检索质量。

通过更好的 Chunk、Embedding、混合检索、Rerank 和 metadata 过滤，保证输入资料相关。

第二，在 Prompt 中限制模型。

明确要求：

text

只能根据提供的上下文回答。
如果上下文没有答案，请回答“未找到依据”。
不要编造未提供的信息。

第三，做答案依据校验。

生成后检查答案中的关键事实是否能在引用 Chunk 中找到。

第四，处理低置信度场景。

如果检索分数太低、Rerank 分数太低、来源冲突，就不要强答，可以提示用户补充问题或转人工。

第五，返回引用来源。

让用户能看到答案依据，增强可验证性。

第六，做版本和权限过滤。

避免召回过期文档或用户无权访问的文档。

一个好的 RAG 系统应该允许“不知道”，而不是为了看起来智能而编造答案。

20、GraphRAG与传统RAG有什么区别？

传统 RAG 主要基于文本 Chunk 和向量相似度检索。用户提问后，系统找出语义相似的片段，再让 LLM 生成答案。

GraphRAG 则会引入图结构，把实体、关系、社区、路径等信息也纳入检索和推理过程。

区别可以从几个方面看。

第一，数据组织方式不同。

传统 RAG 通常是：

text

文档 → Chunk → Embedding → 向量索引

GraphRAG 通常会多一步：

text

文档 → 实体抽取 → 关系抽取 → 构建图谱 → 图检索 / 图推理

第二，检索方式不同。

传统 RAG 主要找语义相似文本。

GraphRAG 可以根据实体关系、图路径、邻居节点、社区摘要来检索。

第三，适合的问题不同。

传统 RAG 适合回答某段文档里能直接找到答案的问题。

GraphRAG 更适合多实体、多关系、多跳推理的问题。

例如：

text

某个系统故障会影响哪些业务？
某个客户和哪些合同、项目、负责人有关？
某个政策变化会影响哪些流程？

第四，可解释性不同。

GraphRAG 可以给出关系路径，例如：

text

服务 A → 依赖服务 B → 连接数据库 C → 影响业务 D

这种路径比单纯返回相似 Chunk 更容易解释。

第五，建设成本不同。

传统 RAG 实现更简单，成本更低。GraphRAG 需要实体抽取、关系建模、图谱更新和一致性维护，复杂度更高。

简单总结：

text

传统 RAG：擅长语义召回
GraphRAG：擅长关系推理和全局关联分析

实际项目里，两者通常不是替代关系，而是组合使用。

21、如果RAG系统返回0个检索结果，你会如何排查问题？

RAG 返回 0 个检索结果时，要从数据、索引、查询、过滤和检索参数几个层面排查。

第一，确认知识库是否有数据。

先看原始文档是否已经成功上传、解析、切分并入库。如果文档没有入库，检索一定为空。

第二，检查向量是否生成成功。

有些系统文档内容入库了，但 Embedding 生成失败，导致向量字段为空或索引不可用。

第三，检查索引是否构建完成。

向量数据库可能存在异步建索引过程。如果索引还没完成，可能查不到结果。

第四，检查查询是否正常向量化。

用户问题也要生成 query embedding。如果 query embedding 调用失败、维度不匹配或模型配置不一致，也会返回空。

第五，检查 Embedding 模型是否一致。

入库时和查询时最好使用同一个 Embedding 模型。不同模型生成的向量空间不同，混用会导致检索失效。

第六，检查过滤条件是否过严。

很多 0 结果不是向量检索失败，而是 metadata filter 把结果过滤掉了。

例如：

text

tenant_id 错误
project_id 错误
doc_type 不匹配
status 只查 published，但文档还是 draft
权限列表为空
时间范围过窄

第七，检查相似度阈值是否太高。

如果设置了 score threshold，阈值过高会把所有结果过滤掉。可以临时降低阈值或关闭阈值验证。

第八，检查 TopK 是否配置异常。

比如 TopK 被设置成 0，或者调用参数没有传对。

第九，尝试关键词检索或直接查库。

如果关键词能搜到，说明文档存在，问题可能在向量索引或 Embedding。如果关键词也搜不到，可能是入库或过滤问题。

第十，查看检索链路日志。

重点看：

text

query 原文
改写后的 query
query embedding 维度
使用的 collection/index
metadata filter
TopK
score threshold
返回数量

排查时可以先用最小条件验证：

text

不加权限过滤
不加 score threshold
TopK 设置为 10
直接用明确关键词提问

如果这样能搜到，再逐步加回过滤条件和阈值，定位是哪一步导致 0 结果。

08 RAG面试题 ​

1、什么是RAG？ ​

2、Agent为什么需要RAG？ ​

3、RAG完整流程是什么？ ​

4、Embedding是什么？ ​

5、向量数据库原理是什么？ ​

6、Chunk如何切分？ ​

7、Chunk大小如何确定？ ​

8、TopK如何选择？ ​

9、Rerank有什么作用？ ​

10、如何提高检索准确率？ ​

11、如何解决知识库召回错误？ ​

12、如何评估RAG效果？ ​

13、请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？有哪些优势？ ​

14、RAG 怎么解决 LLM 上下文窗口有限的问题？ ​

15、如何选择一个合适的嵌入模型？评估一个 Embedding 模型的好坏有哪些指标？ ​

16、在什么场景下，你会选择使用图数据库或知识图谱来增强或替代传统的向量数据库检索？ ​

17、传统的 RAG 流程是”先检索后生成”，你是否了解一些更复杂的 RAG 范式，比如在生成过程中进行多次检索或自适应检索？ ​

18、RAG 系统在实际部署中可能面临哪些挑战？ ​

19、什么是RAG中的”幻觉”问题？如何预防？ ​

20、GraphRAG与传统RAG有什么区别？ ​

21、如果RAG系统返回0个检索结果，你会如何排查问题？ ​

08 RAG面试题

1、什么是RAG？

2、Agent为什么需要RAG？

3、RAG完整流程是什么？

4、Embedding是什么？

5、向量数据库原理是什么？

6、Chunk如何切分？

7、Chunk大小如何确定？

8、TopK如何选择？

9、Rerank有什么作用？

10、如何提高检索准确率？

11、如何解决知识库召回错误？

12、如何评估RAG效果？

13、请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？有哪些优势？

14、RAG 怎么解决 LLM 上下文窗口有限的问题？

15、如何选择一个合适的嵌入模型？评估一个 Embedding 模型的好坏有哪些指标？

16、在什么场景下，你会选择使用图数据库或知识图谱来增强或替代传统的向量数据库检索？

17、传统的 RAG 流程是”先检索后生成”，你是否了解一些更复杂的 RAG 范式，比如在生成过程中进行多次检索或自适应检索？

18、RAG 系统在实际部署中可能面临哪些挑战？

19、什么是RAG中的”幻觉”问题？如何预防？

20、GraphRAG与传统RAG有什么区别？

21、如果RAG系统返回0个检索结果，你会如何排查问题？